Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 003 / mrim004.arc / MICRORIM.004

Wrap

Text File | 1987-02-18 | 37.8 KB | 987 lines

Volume 2 - Number 1 January 1987 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: *************** :: :: ********************* :: :: *************************** :: :: ****************************** :: :: **************** ************ :: :: *************** ************* :: :: *************** ************** :: :: *************** *************** :: :: **************** ***************** :: :: ***************** ************* :: :: ***************** ************** Microrim ONLINE :: :: ****************** *************** """"""""""""""" :: :: ****************** **************** Online Technical News :: :: ****************** ***************** :: :: ****************** ****************** :: :: ****************** ******************* :: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Technical tips, techniques, and announcements from Microrim, Inc. Microrim ONLINE is published electronically approximately every month by Microrim, Inc. and distributed exclusively on the Microrim Bulletin Board System (BBS). You can obtain your copy free of charge by downloading it from the TECH-ED area of the FILES section. (206) 881- 8119. Setup: 8 data bits, 1 stop bit, No parity, and 300 or 1200 baud; operating 24 hours, seven days a week. COPYRIGHT """"""""" Copyright (c) 1986 by Microrim, Inc. All rights reserved. Microrim, Inc. authorizes the free distribution of this document for educational purposes as long as no charge is made and this document is distributed exactly as is without modification. Toward this end, this document may be stored in, uploaded to, and downloaded from any Bulletin Board Service (BBS) or electronic information service as long as no charge is made. CONTRIBUTIONS """"""""""""" You are encouraged to contribute to MICRORIM ONLINE. Please upload your article, application, or application story to the Microrim BBS or send an IBM compatible disk in standard ASCII format to: Kay D. Dayss, Microrim ONLINE Editor Microrim, Inc. 3925 159th Ave. N.E. P.O. Box 97022 Redmond, WA 98073-9722 By submitting an article or application to MICRORIM ONLINE, you agree that the material is not confidential and that Microrim, Inc., may use, duplicate, modify, publish, or sell it without obligation or liability to you or anyone else. MICRORIM ONLINE January 1987 -------------------------------- Page 1 TRADEMARKS """""""""" R:BASE and MICRORIM are registered trademarks of Microrim, Inc. XRW is a trademark of Microrim, Inc. IBM is a registered trademark of International Business Machines Corp. XT and AT are trademarks of International Business Machines Corp. DISCLAIMER """""""""" Microrim, Inc., makes no representation or warranties with respect to the contents hereof, and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Further, Microrim, Inc., reserves the right to revise this publication and to make changes in the content hereof without obligation to notify any person of such revision or change and shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material. Opinions and product reviews appearing in MICRORIM ONLINE are those of the author and not necessarily those of Microrim, Inc. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: TABLE OF CONTENTS :: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: TECHNICAL NOTES R:BASE System V Version 1.1 Upgrade................................ 3 Improve Security and Verify Entered Passwords...................... 13 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: MICRORIM ONLINE January 1987 -------------------------------- Page 2 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: TECHNICAL NOTES :: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" R:BASE SYSTEM V VERSION 1.1 UPGRADE """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" DATE : 12/86 NUMBER : EX-12-1 PRODUCT : R:BASE SYSTEM V VERSIONS : 1.0 TO 1.1 CATEGORY : ANOMALIES SUBCATEGORY : 1.1 UPGRADE """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" NEED: What are the differences between R:BASE System V version 1.0 and the new R:BASE System V version 1.1? What anomalies in R:BASE System V version 1.0 were addressed in version 1.1? SOLUTION: R:BASE System V version 1.1, provides connectivity enhancements and also addresses anomalies found in version 1.0. ENHANCEMENTS: ============ The enhancements give you greater data import and export capabilities. The R:BASE System V version 1.1 update gives you: o Connectivity to mainframe databases with Lotus Development Corporation's The Application Connection (T-A-C) in combination with R:BASE System V FileGateway. o Connectivity to dBASE databases with the ability to export to dBASE III and dBASE III PLUS files. o The ability to unload data into an ASCII file directly from the R> prompt with the UNLOAD AS ASCII command. With R:BASE System V version 1.1 on your microcomputer, and Lotus's T- A-C on both the mainframe and the microcomputer, your R:BASE System V database has access to data in mainframe databases such as RAMIS, FOCUS, SAS, APL/DI, ADRS2, IC/1, NOMAD2 and SQL. T-A-C translates the data in the mainframe database into a transfer file and then FileGateway (from R:BASE System V version 1.1) loads the transfer file directly into an R:BASE System V database. You can also export data to your mainframe with FileGateway by choosing the Lotus transfer file format. You then use Lotus's The Application Connection to transfer the data to the mainframe. This special connectivity saves you time and prevents you from having to key data into both your mainframe and your micro. ANOMALIES FIXED IN VERSION 1.1: ============================== Anomalies in R:BASE System V version 1.0 have been addressed in version 1.1. Most of the anomalies in version 1.0 were minor and occurred in only a few specialized situations and under unusual conditions. Some anomalies were intermittent and others only happened under certain conditions. MICRORIM ONLINE January 1987 -------------------------------- Page 3 The following five anomalies in R:BASE System V version 1.0 were encountered more often than the others and have been corrected in R:BASE System V version 1.1: o In version 1.0, when you put a multi-tiered region on page two, three, four, or five of a form, the region did not scroll correctly. The data loaded into the table correctly, but only the first or the last tier scrolled, the other tiers did not move up (or down). Regions located on page one worked correctly. Version 1.1 regions scroll correctly on all pages. o In version 1.0, a rule to prevent duplicate rows did not always work. o In version 1.0, sometimes keys on columns would go bad. These bad keys could make it look as if you had duplicate rows in your table when in fact you did not. Corrupted keys also sometimes made it look like data that was in your table had disappeared. The data was still there, but you had to remove the key (or not use it) to access the data. o In version 1.0, if you attempted to delete data in a field with the [F2], [Shift-F2], [Del], or spacebar keys during an edit session, sometimes the computer would stop responding to your keystrokes and you had to reboot the computer. o Some version 1.0 users experienced anomalies with NOTE columns. This was particularly apparent when customers attempted to do illegal operations with NOTEs. Instead of trapping the illegal operation, R:BASE attempted to do it and sometimes data was corrupted. Now, in version 1.1, R:BASE traps more of the illegal operations and gives error messages. The following is a list of anomalies by product area. Each of these 1.0 anomalies have been addressed in version 1.1 of R:BASE System V: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: APPLICATION EXPRESS ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o MACROS If you pulled in a macro, in version 1.0, that already had $COMMAND at the beginning, you may have gotten the error message, "I/O error - Check for full disk" when you tried to modify the application. Also, if you pulled in a macro that contained a plus sign (+) to continue a command line in either column 79 or 80, the plus sign may have moved to the beginning of the next line when Application EXPRESS wrote the binary application file (the .APX file). After that, the command may not have executed properly when the application was run using the .APX file. The .APP file (non- compiled file) worked correctly and if you compiled the macro into a stand-alone binary file using CODELOCK, it worked. MICRORIM ONLINE January 1987 -------------------------------- Page 4 o PRINTING A REPORT In 1.0, a user happened to SET CASE ON. The horizontal menu that Application EXPRESS created to select the print output device had "printer" spelled "Printer." The IF statement to check for output device said "IF ... = PRINTER." With CASE ON, these were not equal. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: GATEWAY ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o DISPLAY TABLES [F3] KEY In version 1.0, with both import and export, at the "Choose a Table" menu, if you pressed [F3], then chose (ALL) to display all tables, you could see the structure of all tables, even password- protected ones that do not show up on the "Choose a Table" menu. o IMPORTING WITH ADD (OPTION 1) With 1.0, you could not use "Add" (option 1 from the menu) to import data into a table if you had deleted all the rows from the table and packed the database with the PACK or RELOAD commands. All other import options worked, and "Add" worked if you had not packed the database. o IMPORTING ASCII FIXED FIELD FILES With 1.0, if you imported an ASCII fixed field file, and chose to replace the existing rows in a table, you needed to delete keys and rebuild them. Otherwise, a LIST of the table showed the correct number of rows but the following command brought up all the new rows as well as the old ones (that were supposed to have been replaced): SELECT ALL FROM tblname WHERE colname = value If you deleted keys with the DELETE KEY command, the old rows no longer displayed. o IMPORTING FILES WITH MORE THAN 30,000 RECORDS In 1.0, after a large number of rows (about 32767), the row counter changed to negative and began to count backwards. o IMPORTING DOLLARS FROM LOTUS In version 1.0, when you imported dollars from Lotus, amounts were off by $.01. You had to bring the number in as REAL or DOUBLE and then convert it to CURRENCY in R:BASE. MICRORIM ONLINE January 1987 -------------------------------- Page 5 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: GENERAL R:BASE ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o KEYS Two anomalies with version 1.0 keys were addressed in version 1.1. In the first anomaly, bad keys made it appear that there were duplicate records in a table. If column1 was keyed, and the key had gone bad, and you issued the command: SELECT ALL FROM tblname WHERE textcol = value you might have seen two rows listed on the screen when there was only one row that met the WHERE clause. However, if you changed the command to: SELECT ALL FROM tblname WHERE textcol CONTAINS value you saw only the one row because the CONTAINS operator does not use keys. In the second anomaly, corrupted keys in version 1.0 made it look like a row that really was in your database, was not there. If you used a keyed column in a WHERE clause with the EQ operator (which uses keys), and the key was bad, the row was not found. However, if you used the CONTAINS operator (which does not use keys), the row was found. The problem is easily corrected by deleting keys with the DELETE KEY command and then rebuilding them with the BUILD KEY command. R:BASE System V version 1.1 helps to prevent keys from getting corrupted in the first place. o BACKUP AND RESTORE In version 1.0, if had a RULES table or had defined VIEWs, and you used the BACKUP ALL to back up your database, you could have some difficulty restoring the database depending on the order of the tables. In the case of RULES, the problem occurred when there was a rule making a value in one table dependent on a value in another table and the RULES table appeared before the other two tables in the table list. During restoration R:BASE would restore RULES and then start to restore the first data table. R:BASE would then see a rule violation because the second data table had not yet been restored. A similar situation could occur if tables containing column definitions that were also in VIEWs were not restored before the VIEW was restored. R:BASE System V version 1.1 resolves the situation by always putting the RULES table and VIEWs last in the list when backing up with the R:BASE System V BACKUP command. o EXPAND In version 1.0, the EXPAND command removed read and modify passwords (RPW and MPW) if there were any on the table. MICRORIM ONLINE January 1987 -------------------------------- Page 6 o EXPRESSIONS IN WHERE CLAUSES In version 1.0, sometimes, after a report with a lookup variable had been printed, any command using an expression in a WHERE clause would return the message: -ERROR- Cannot use an expression in a WHERE clause for this command o JOIN In 1.0, if you used the JOIN command to join two tables based on a common TEXT column and one of the two tables also had a NOTE type column, the resulting table could have spurious characters in it. o REMOVE COL AND EXPAND Whenever a computer is writing to disk, it is important to try to keep from interrupting the process. It is similar to trying to stop a car on the freeway, there is a response time that can sometimes cause skid marks. In version 1.0, sometimes the REMOVE COLUMN and EXPAND commands would not leave the table intact if you aborted them by pressing the [Esc] key. The numbers of rows could be less or zero. We have addressed this in version 1.1, and now it is more difficult to cause damage. However, we still do not recommend interrupting any process that involves writing to disk unless you are prepared to go to your backup. o CHANGE COMMAND AND NOTE COLUMNS Using the CHANGE command to put a TEXT expression into a NOTE column is not a legal operation. In version 1.0, if you tried it anyway, R:BASE may have put spurious characters into your table and into memory. In version 1.1, you get an error message. o RULES, DUPLICATES, AND ENTER FORM If you had a rule to prevent duplicate rows from being entered, version 1.0 forms did not check rows entered during the current session against each other. For example, if you had a rule to prevent duplicate entries of an ID number, version 1.0 would allow you to enter duplicates if you entered both rows without exiting to the R>. o SELECT, VIEWS, AND A SORTED BY CLAUSE In version 1.0, if you SELECT ALL FROM viewname SORTED BY colname, even with ESC set on you could not cancel the command and abort out of the process by pressing a key. You could, however, escape from the process if you removed the SORTED BY clause. o UNLOAD AND NULL In version 1.0, if you unloaded data using the UNLOAD DATA command with NULL set to blank, null values unloaded as multiple commas (,,,,) where two commas = one field, three = two fields, etc. Using INPUT, the data loaded back in correctly regardless of whether NULL is set to blank, or some other character. However, when a row ended with two or more null fields, the row did not load back in correctly because the UNLOAD caused the row to be one comma MICRORIM ONLINE January 1987 -------------------------------- Page 7 short. In version 1.1, rows load back in correctly in all cases. o VIEWS, EDIT ALL, AND BROWSE In 1.0, EDIT ALL or BROWSE commands, performed on a single table VIEW that had been defined with a WHERE clause, ignored the WHERE clause. In other words, all the rows were brought up instead of only the rows selected by the WHERE clause. o VIEWS AND NOTES In 1.0, if you had a VIEW with a NOTE column in it and you issued a command involving a sort or a SORTED BY clause, your disk could fill up very quickly. In version 1.1, the temporary sort files take up less space than they did in version 1.0. o VIEWS AND COMPUTE In 1.0, COMPUTE on a VIEW showed rows = -1. This was changed in version 1.1 to N/A to be consistent with the rest of the product. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: FORMS ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o DEVELOPING A FORM - USING #DUP In version 1.0, if you used #DUP on a text field 40 characters or more characters long, you might have seen the literal word #DUP displayed in the field (instead of the value from the previous row). If you located a smaller field after the larger text field, #DUP worked correctly. o DEVELOPING A FORM - SECOND TABLE WITHOUT LOCATED FIELDS OR TEXT In 1.0, if you had a second table associated with a form, but no fields located for it, sometimes blanks or underlines appeared in the upper left hand corner of the form. o DEVELOPING A FORM - MULTI-TABLE FORM In version 1.0, if you had 10 or more common columns defined, and you pressed the [F8] key for the next table, you could get the message: -WARNING- Table newtab has no common columns with the previous table(s) even though there were common columns. o DEVELOPING A FORM - REORDER FIELDS In 1.0, When reordering the fields in forms, if you paged down through the column list and then paged back up, R:BASE appeared to skip a column. Pressing [PgDn] displayed columns 1-15, 16-30, 31- 45 etc., [PgUp] showed 17-31, 1-15. Column 16 was skipped. The missing column reappeared if you pressed [PgDn] again. MICRORIM ONLINE January 1987 -------------------------------- Page 8 o ENTER FORM OR EDIT USING A FORM - SCROLLING REGIONS In 1.0, when you entered or edited data in a region located on pages two, three, four, or five of a form, only the top or bottom tier of a region scrolled through the rows instead of the all of the rows cycling through the entire region area. Regions located on page one worked correctly. The data was not affected. o ENTER FORM OR EDIT USI FORM - NOTE COLUMNS In version 1.0, when there were two or more fields with a NOTE data type on the form, R:BASE did not check to see if you were exceeding the maximum row length limit. If you did exceeded the limit, you could have seen a memory dump, or highlighted screen blocks. To get out of it, you needed to press [F2] to delete what was in the field, then press [Esc] and choose "Save" (to exit the form), then exit R:BASE, and reboot your computer. o ENTER FORM OR EDIT USING A FORM - HELP SCREEN NOT CLEARING In 1.0, the help screen (brought up by pressing [F10]) was not automatically cleared when called from the second page in a form. You needed to press the [PgUp] or [PgDn] keys to clear the screen. The [Esc] key only showed the highlighted fields through the help screen. o ENTER FORM - FROM FILE In 1.0, ENTER FORMNAME FROM FILENAME sometimes loaded inaccurate CURRENCY values. o ENTER FORM - AND [PGDN] PAST THE PAGES YOU HAVE Sometimes, in version 1.0, if you used the ENTER FORMNAME command on a three-page form (with one table per page), the [PgDn] key cycled past page three and would show spurious characters on the screen. o EDIT USING FORM - DELETING THE CONTENTS OF FIELDS In 1.0, if you used the EDIT USING command to edit your data and attempted to delete the information in a field, your computer may have stopped responding to keystrokes. Rebooting the computer fixed the problem. o EDIT USING FORM - DATE AND TIME EXPRESSIONS In version 1.0, if a form had two expressions: TDATE = .#DATE and CTIME = .#TIME (where TDATE and CTIME were column names), and you entered the command: EDIT USING FORMNAME, sometimes only the second expression would be evaluated. If a dummy expression like DUMMY = xxx was put first, then both the TDATE and CTIME expressions were always evaluated. MICRORIM ONLINE January 1987 -------------------------------- Page 9 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: FUNCTIONS ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o SLEN In 1.0, the following illegal command did not generate an error message: SET V V1 TO "ABCDE";SET V V2 TO (SLEN(SGET(.V1,1,1))) The command is illegal because it has a function embedded as the argument for a text function. Once this illegal command was executed, all further SLEN uses returned a value of null, even if they had a valid expression. To correct it, you had to exit from R:BASE and then bring R:BASE back up again. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: PROMPT-BY-EXAMPLE (PBE) ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o CHANGE In 1.0, you could not select (ALL) columns when executing the CHANGE command from the "All Commands" menu. The screen displayed the message: Choose a table -- press [Esc] for all but [Esc] took you back to PBE Main Menu. o PRINT VIEW In 1.0, you could not print a report on a VIEW two times in a row from PBE, you got the error message: Rptname is an undefined report. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: PROGRAMMING ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o ERROR VARIABLES The error variable may have behaved inconsistently in version 1.0 depending on the command used and the setting of messages and error messages. For example, if you issued the RUN filename command, and the file could not be found, the error variable was set to zero if you had previously SET MESSAGES OFF and SET ERROR MESSAGES ON, but if you had previously SET MESSAGES ON and SET ERROR MESSAGES OFF, the error variable was set to 2004. o LABEL In 1.0, the LABEL command could not be the last command in a command file. If it was, you got the error message: -ERROR- Unable to find matching LABEL for <labelname> MICRORIM ONLINE January 1987 -------------------------------- Page 10 o SET POINTER AND REMOVE COL In version 1.0, if you issued a SET POINTER #2 command on a table, and then later attempted to remove a column in that table with the REMOVE COL command, the SORTED BY clause no longer worked on any command. You needed to exit from R:BASE and come back in to get the SORTED BY clause to work again. Entering SET POINTER #2 OFF right before the REMOVE COL prevents the anomaly from occurring: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: REPORTS ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o PAGE HEADER In version 1.0, if only page headers, break footers, and other footers were marked on a report (in other words, there were no break header or detail lines), the page header would not print on the first page of the report. o LOCATING LOOKUP VARIABLES In 1.0, if you pressed [F6] to locate variables defined as lookups, after some number all the markings on the left side would disappear and the cursor number at the bottom stated that you were on line 800 (or something else that is invalid). Recovering required exiting from Reports EXPRESS. o EXPRESSIONS If you defined an expression in a version 1.0 report, when the variable name was less than 8 characters long and there were no spaces around the equal sign, R:BASE picked up the first eight characters as the variable name, including the =. However, the entire expressions past the = was correct. For example, the expression: VAR1=SUM OF COLUMN was written to the REPORTS table as VAR1=SUM = SUM OF COLUMN Also, if you made a mistake when typing in an expression in reports, after the error message is given, you had to completely retype the expression. Version 1.1 allows you to edit what was typed in initially. o CONCATENATION In version 1.0, if you concatenated last name, first name, and middle initial, and the middle initial field (TEXT 1) was NULL, all fields located after the concatenated field on that line of the MICRORIM ONLINE January 1987 -------------------------------- Page 11 report are sometimes shifted one character to the left when printed to a printers or file. On the screen the report looks fine. o RUNNING OUT OF BUFFER SPACE Occasionally, Reports did not correctly allocate sufficient buffer space to process all reports expressions and gave the message: -ERROR- Insufficient buffer space o LOOKUPS TO NOTE COLUMNS In version 1.0, you could occasionally get spurious characters printed if your report did a lookup to a NOTE column. o VIEWS AND LOOKUPS In a version 1.0 report based on a VIEW, sometimes R:BASE added a column value twice if a lookup it was doing failed. Other times, if the report (based on a VIEW) was looking up a value in a table outside of the view, R:BASE stopped processing rows in the view after a lookup failed. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: RBDEFINE ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o RESERVED COLUMN NAMES Version 1.0 Definition EXPRESS allowed you to use the reserved words FNAME, RNAME, FDATA, and RDATA as columns with any data type. o MODIFY EXISTING TABLE In version 1.0, if you suddenly changed your mind in the middle of defining a new TEXT column to insert into an existing table using Definition EXPRESS, and pressed the [Esc] key twice after stating the data type was TEXT but before giving the length of the column, and then chose to leave Definition EXPRESS, you got the message, "Adjusting table" and the database may be corrupted. :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: RBEDIT ANOMALIES ADDRESSED IN VERSION 1.1 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Any file with special characters (such as form feeds) becomes a playback file with [ENTER] and other keystrokes entered directly into the file, when the file is edited with RBEDIT. Version 1.1 gives you a choice when editing a file with these special ASCII characters in it. MICRORIM ONLINE January 1987 -------------------------------- Page 12 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" IMPROVE SECURITY AND VERIFY ENTERED PASSWORDS """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" DATE : 12/86 NUMBER : EX-12-2 PRODUCT : R:BASE SYSTEM V VERSIONS : ALL CATEGORY : PASSWORDS SUBCATEGORY : SECURITY/PROTECTION """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" NEED: The USER command provides excellent security because as the operator is keying in a password, it is not displayed on the screen. However, the operator is not able to visually verify the password so I need a way to verify that the correct password has been entered. I want the operator to know immediately rather than having to wait for an access to a table or view to be denied. If access is denied in the middle of a custom written program, it will be inconvenient for the operator to go back to the beginning and enter the password again. In addition, I want the procedure to be easily tacked onto the beginning of macros and command files so that the correct password is entered for access to the tables and views in that procedure. At the end of the procedure, I want to erase the password. This will help to strengthen the overall security for my application. SOLUTION: Frank Aquiningoc shares the following basic building block for meeting this need: The following is a simple password verification subroutine which does not know the password of any table or view and can therefore be used generically and modified to fit particular circumstances. This simple subroutine assumes that all or one table, view, or form is password-protected. You can expand this procedure and use it for other individual table accesses for a more sophisticated system. THE BASIC CONCEPT: ================= The subroutine follows these six steps. 1. Sets the error variable. 2. Asks the operator for his or her password. 3. Selects from the table or view using a WHERE clause that will never be true. In this example I check for an account number equal to zero because I know that all account numbers are greater than zero. Since account number is a keyed column, I know that the access check will be fast. 4. Checks the error variable for invalid user access. 5. If the operator has entered an invalid password, the user has two more chances to enter a valid password. If the password is valid, MICRORIM ONLINE January 1987 -------------------------------- Page 13 a flag variable named VALID (or any name you want) is set to "YES". Otherwise, VALID has a value of "NO" 6. The subroutine ends and the calling program uses the flag variable VALID to allow or deny access to the program routines that use the table or view that requires that password for access. THE SUBROUTINE LISTING ====================== *( PASSWORD.CMD ) *( Author: Frank Aquiningoc ) *( Date: December 23, 1986 ) *( Program: This program prompts the user for password input then verifies) *( the password based upon the table or view to be accessed. ) *( The user has chances to enter the password, then the program ) *( will return with the flag variable VALID set to YES or NO. ) *( This program assumes that the database has been opened and a ) *( MPW {modify password} has been defined ) SET ERROR MESSAGE OFF SET MESSAGE OFF SET ESCAPE OFF CLEAR CNTLOOP VALID SET VAR CNTLOOP TO 1 SET VAR VALID TO "NO" SET ERROR VAR ERRORVAR NEWPAGE WHILE CNTLOOP LE 3 THEN USER *( Change the next line to match your table {rather than accounts} and) *( your "never true" WHERE clause {rather than ACCT# = 0}. ) *( Note that the EDIT command is used because this example is testing ) *( a modify password {MPW}. If you were testing a read password {RPW}) *( you could use the SELECT command instead. ) EDIT ALL FROM accounts WHERE acct# = 0 *( Error variables that apply here are: ) *( 2039 - unauthorized access to the table ) *( 133 - the USER and OWNER password must match ) *( 303 - the USER and OWNER password must match ) *( check for these error values, if they occur, ) *( the user password is wrong. Loop back to ) *( have the user reenter password ) IF ERRORVAR = 2039 OR ERRORVAR = 133 OR ERRORVAR = 303 THEN BEEP WRITE "INVALID PASSWORD" AT 1,25 SET VAR CNTLOOP TO (.CNTLOOP + 1) ELSE *( set loop to 3 to exit out of loop ) MICRORIM ONLINE January 1987 -------------------------------- Page 14 *( set flag valid to yes ) SET VAR CNTLOOP TO 4 SET VAR VALID TO "YES" ENDIF NEWPAGE ENDWHILE RETURN FURTHER MODIFICATIONS ===================== You may wish to further modify this subroutine and include an appropriate version of it at the beginning of every custom macro or command file that you write. Combining this subroutine with read and modify passwords on your tables and views can provide powerful security for your sensitive data. If you follow this option, include the following command at the close of each macro or command file: USER NONE CLEAR VALID This will clear the current user password from memory and will remove the VALID variable from memory. Now, when control is passed back to the keyboard at the completion of the procedure, an unauthorized person cannot gain access. In addition, SET ESC OFF (at the beginning) to prevent interruption of the macro or command file, and make sure that the macro has been encoded by running it through Application EXPRESS or CodeLock. MICRORIM ONLINE January 1987 -------------------------------- Page 15